AOL File Library: 9,300 to 9,399/9300.zip/AOLDLs/E-Zines/EZINE_ TidBITS#335 (MAC)/tb335.txt

Text File | 2014-12-11 | 31KB | 587 lines

TidBITS#335/08-Jul-96
=====================

After a week off, we return with the second part of Geoff's
   detailed look at the PowerPC chip and other bits of Macintosh
   architecture. Adam weighs in with advice for people who have to
   give Internet presentations, and Tonya looks at a couple of Web
   browser plug-ins that help browsers both talk and listen, along
   with a new mailing list called Disabled-Talk. MailBITS about the
   release of the commercial System 7.5.3 and BBEdit 4.0.1 round out
   the issue.

This issue of TidBITS sponsored in part by:
* APS Technologies -- 800/443-4199 -- <[e-mail]>
   Makers of hard drives, tape drives, and neat SCSI accessories.
   For APS price lists, email: <[e-mail]>
* Northwest Nexus -- 206/455-3505 -- <http://www.halcyon.com/>
   Providing access to the global Internet. <[e-mail]>
* Power Computing -- 800/375-7693 -- <[e-mail]>
   PowerTower 180 MHz - the fastest Mac OS system ever made.
   Win a PowerCenter 120! <http://www.powercc.com/>
* America Online -- 800/827-6364 -- <http://www.aol.com/>
   The world's largest provider of online services.
   Give Back to the Net -- <http://www.aol.com/give/>
* EarthLink Network -- 800/395-8425 -- <[e-mail]>
   Providers of direct Internet access for Macintosh users.
   For eWorld refugees: no setup fee! <http://www.earthlink.net/>
* DealBITS: Great deals on Macs, utilities, and programming tools!
   <http://www.tidbits.com/dealbits/> -- <[e-mail]>

Copyright 1990-1996 Adam & Tonya Engst. Details at end of issue.
   Information: <[e-mail]> Comments: <[e-mail]>
   ---------------------------------------------------------------

Topics:
    MailBITS/08-Jul-96
    Plain Talk on the Internet
    Presenting the Internet
    Fishing For Chips: Part 2

<ftp://ftp.tidbits.com/pub/tidbits/issues/1996/TidBITS#335_08-Jul-96.etx>


MailBITS/08-Jul-96
------------------

**Apple's Call for Unity** -- Apple has finally released the
  long-awaited retail version of System 7.5.3. This version can
  install a universal system that will boot anything from a Mac Plus
  onwards. Codenamed Unity, the retail version of System 7.5.3
  includes the fixes from System 7.5.3 Revision 2 (see
  TidBITS-332_), LaserWriter 8.3.4 (see TidBITS-333_), support for
  8x CD-ROM drives, the Apple Internet Connection Kit, and an
  optional installer for OpenDoc 1.0.4. The software costs $99 and
  should be available shortly through the usual retail software
  channels on floppy disk or CD-ROM; current System 7.5 owners can
  upgrade for $49 by calling 800/293-6617, ext. 1 with proof of
  ownership. For many Mac users and support personnel, installing
  System 7.5.3 required running through an involved series of
  installers, downloads, and patches - it's nice that Apple finally
  put everything together in a single release, even if it will soon
  be eclipsed by new versions of Open Transport and other system
  components. Apple says international versions of Unity should be
  available in the next 90 days. [GD]

<http://product.info.apple.com/pr/press.releases/1996/q4/
960702.pr.rel.macos.html>


**BBEdit 4.0.1 Update** -- Bare Bones Software released an update
  to BBEdit 4.0.1, which includes improved HTML tools, the ability
  to edit and store text files on an FTP server directly, and
  (notably!) multiple undos. The update is free to existing BBEdit
  4.0 customers; the update does not work with any version of BBEdit
  Lite. [GD]

<ftp://ftp.barebones.com/pub/updaters/>


Plain Talk on the Internet
--------------------------
  by Tonya Engst <[e-mail]>

  Interested in interfacing with the Web using sound? Two browser
  plug-ins, ListenUp and Talker, enable you to do just that. I've
  used both plug-ins without crashes in both Netscape Navigator 2
  and Internet Explorer 2 on my Power Macintosh 7100. Both plug-ins
  require that you install PlainTalk, Apple's speech recognition
  technology, which comes with Apple's System 7.5 and can also be
  downloaded from various online venues.

<ftp://ftp.info.apple.com/Apple.Support.Area/Apple.Software.Updates/US/
Macintosh/System/PlainTalk_1.4.1/>

  Written by Bill Noon, ListenUp 1.41 enables you to follow links by
  speaking their names. There are a few catches: you must have a
  Power Mac equipped with a PlainTalk microphone, run System 7.5 or
  newer, and be following a link on a Web page specially coded to
  work with ListenUp. In addition, you must be lucky enough to have
  voice recognition usually work for you; I've only had moderate
  success in this department. Web authors who wish to support
  ListenUp must include a short bit of additional HTML on their
  pages (for those in the know, that short bit is an <EMBED> tag),
  and they must also place on their Web servers a text file that
  associates link text with URLs.

<http://snow.cit.cornell.edu/noon/ListenUp.html>

  In contrast to ListenUp, which helps Web browsers listen, Talker
  2.0 makes Web browsers talk. The free plug-in from MVP Solutions
  lets you hear the text displayed on Web page. A Talker-enabled Web
  page displays onscreen in the normal, visual fashion, but your Mac
  automatically speaks the words on the page. Web authors can even
  set up pages such that different bits of text are spoken, or even
  sung, in different voices. To use Talker, you must have the
  English Text-to-Speech component of PlainTalk installed. The
  Talker Read Me file helpfully discusses how to tell if you have
  the right software installed, and what to do if you don't.

<http://www.mvpsolutions.com/PlugInSite/Talker.html>

  TidBITS doesn't currently support ListenUp- or Talker-savvy HTML,
  but I wouldn't rule it out for future issues. However, instead of
  HTML authors adding special HTML tags to enable their pages for
  speech, it would be nice to see more browsers support speech. For
  instance, NCSA Mosaic 3.0b2 can speak the contents of pages
  without requiring special HTML. A sufficiently savvy browser might
  even have mannerisms like emphasizing text in <EM> tags or letting
  you configure what voices speak when your Macintosh reads
  differently tagged text. For instance, you might assign headings a
  more authoritative voice than regular body text.

<http://www.ncsa.uiuc.edu/SDG/Software/MacMosaic/>

  One TidBITS reader already uses PlainTalk and his PowerBook during
  his daily commute in order to keep up with TidBITS and other
  online periodicals. He's not a Mosaic user, so it takes some
  setting up on his part, but apparently the time it takes to drive
  from his home in Redmond to his office in downtown Seattle is just
  long enough to listen to a complete TidBITS issue.


**Disabled-Talk** -- If your interest in interfacing with the Web
  via sound has less to do with novelty and more with necessity, or
  if you are generally interested in additional methods of
  interacting with and using a Macintosh, you might wish to join the
  new Disabled-Talk mailing list. The list's charter calls for
  discussions to center on Mac-related techniques and technologies
  that make life easier for people having disabilities or handicaps.
  Such discussions might include information about using sound to
  interface with a Macintosh, screen magnification, and using a Mac
  to automate a variety of tasks, such as turning on lights.

<http://thelorax.res.cmu.edu/lists/disabled.html>


Presenting the Internet
-----------------------
  by Adam C. Engst <[e-mail]>

  I've been giving a number of talks recently at conferences like
  the Adobe Internet Solutions Conference, and I thought I'd share
  some of the tricks and techniques that I've worked up for Internet
  presentations.

  While I was a student at Cornell, my part time job involved
  managing a seminar room with a projector. I've seen (and rescued)
  far too many demonstrations undermined by technical glitches. As a
  result, I tend toward extremely low-tech presentations. Short of
  laryngitis, there's not much that can go wrong if you're just
  talking. Add an overhead projector and the bulb could blow; use a
  Macintosh and the projector can mess things up in any number of
  ways, not to mention all the potential problems of using an
  unfamiliar Mac with unexpected fonts and extensions. Add a live
  Internet connection and you're tempting the laws of Murphy
  (whatever can go wrong, will).

  So, my main advice for any presentation is to keep the level of
  technology involved to a minimum. Obviously, since we're talking
  about Internet presentations, that's difficult, so the corollary
  is that when you must do a high-tech presentation, isolate and
  eliminate as many variables as possible. If you have your own
  PowerBook and can connect to the projector, use your PowerBook
  rather than whatever Macintosh might already be there. If you have
  your own modem, ditto. Anything you can do to stick with a known,
  working situation rather than venturing into the unknown reduces
  your chances of blowing the presentation.

  For Internet presentations these days, I've had extremely good
  luck with doing my "slides" in HTML rather than in a program like
  Persuasion or PowerPoint. Aside from the fact that I don't use
  either of those programs, HTML is extremely flexible. For
  instance, I can put my presentation up on my Web server as a
  backup in case something happens to the copy I bring with me. I've
  never needed that backup, but making slides in HTML also
  simplifies showing off a variety of Web sites as part of the
  presentation - just click and you're there. I've made HTML slides
  for presentations a few times now, and they tend to be extremely
  simple. Each slide usually contains a small graphic at the top and
  then a short list of points. The slide finishes with Next and
  Previous links for moving around. You can make links all over in
  your presentation, but I recommend keeping it mostly linear
  because it's too easy to become flustered while you're on stage.

  The way I create my slides is a little unusual. Working from an
  outline, I go straight through the talk, creating the HTML file
  for each slide as I go. I name the first file something like
  "connect1.html" and when I'm done with that one, I duplicate it in
  the Finder, rename it to "connect2.html" and edit it, which is
  easier and more consistent than trying to do each one from
  scratch. Get the first one right, or else you'll have to make
  changes in all the files after that point. Small changes aren't a
  problem if you use a tool like BBEdit or NisusWriter that can find
  and replace across all the files in a presentation. I've seen
  other HTML slide presentations done as a single long HTML
  document, which you can either scroll through or use internal
  anchor links.

  If you plan to show examples of Web sites during your
  presentation, consider using WebWhacker from The ForeFront Group
  to download some of the site, complete with graphics and internal
  links. That way, if your Internet connection isn't working when
  you give the presentation, it won't matter. It's often a good idea
  to make two links for each sample site, a local one to the
  downloaded version of the site and a remote one to the online
  version of the site, because there are times that you might not
  have downloaded the part of the site you need. More importantly,
  sometimes it's good to show the real speed of the site, rather
  than the speedy canned demonstration from your hard disk.

<http://www.ffg.com/whacker.html>

  Another reason to use HTML for your presentation is that it
  provides a variety of options for which browser you use. Unless
  you present sites that rely on Netscape extensions, for instance,
  it doesn't matter all that much. Tonya likes using MacWeb because
  it provides much more control over onscreen fonts and styles than
  Internet Explorer or Netscape Navigator. Speaking of fonts, when
  you test your HTML at the site of the presentation with the
  projector on, make sure the font you use is readable from the back
  of the room. Netscape, for instance, defaults to using Times 12
  point for its text font, which is small and hard to read onscreen.
  I usually switch to New York 12 point, which is easier on the eyes
  and designed for onscreen readability. If you use separate HTML
  files for each slide, run through your entire presentation to
  ensure you'll have a minimum of scrolling - scrolling distracts
  you from the task at hand, which is speaking.

  No matter what, shut off as many of the toolbars and other fields
  at the top of the window as you can. No one will be able to read
  the Location field, and if your presentation is local, the URLs
  will be useless anyway. Things like Netscape's Directory Buttons
  are pointless for the purposes of the presentation, and take up
  screen space your slides could use to avoid scrolling. Also, many
  people in your audience may not be able to see the bottom third of
  the screen, so you'll want your information to be up at the top
  where everyone can see it. This may seem like a minor point, but
  you don't want to waste screen space or distract your audience
  with unnecessary screen controls, and few presenters seem to
  realize this.

  Since no one can see the URLs for the sites you visit, make sure
  to include them on a handout for the audience. It's a good idea to
  provide a handout anyway, since that keeps people from madly
  taking notes when they should be paying attention to what you're
  saying. For some reason, audiences are always desperate to know
  exactly what URLs you've visited, and URLs are deucedly hard to
  convey in spoken words.

  I don't want to get into the details of actually making the
  presentation, other than two quick points. First, if you only have
  a modem connection, don't apologize for its speed, or, if you
  must, only apologize once. Second, when you take questions from
  the audience (which you definitely should do, but only at
  appropriate breakpoints and again at the end), make sure to repeat
  the question before answering it. Failing to repeat the question
  so everyone can hear it before you answer is probably the most
  common failing of technical presentations.


Fishing For Chips: Part 2
-------------------------
  by Geoff Duncan <[e-mail]>

  In TidBITS-334_, we looked at the PowerPC processor family and
  some of the terms and technologies associated with it. If you read
  the article, your probably know the difference between 68K and
  PowerPC chips, why clock speed and clock multipliers are
  important, the difference between Level 1 and Level 2 caches, and
  the differences among different PowerPC chips. Part 2 builds on
  this information and examines additional software and hardware
  components of the Power Macintosh.


**Emulators Forever** -- If there's a single thing that made the
  Power Macintosh successful, it's the 68K emulator built into its
  system software. Conceptually, the 68K emulator sits between the
  PowerPC processor and executing code. If code is written for the
  PowerPC (such code is considered "native"), the emulator does
  nothing; if the code is written for 68K machines, the emulator
  translates it to PowerPC code (at a very low level) and passes it
  to the PowerPC processor. Without a 68K emulator, non-native
  programs wouldn't run at all on a Power Mac.

  The 68K emulator enabled Apple to move the Macintosh to a new
  processor architecture while retaining strong compatibility with
  existing programs - undeniably a good thing. At the same time, 68K
  emulation is also the Achilles heel of the Power Mac because the
  performance of 68K emulation can't compare to that of native
  PowerPC code. When the Power Macs were introduced, Power Mac users
  often took a step backward in performance because the vast
  majority of Mac software was only available for 68K machines.
  Though some native applications appeared quickly, major tools like
  QuarkXPress, Microsoft Office, and FileMaker Pro took a while to
  become Power Mac-native.

  Further, though Apple has ported many critical portions of the
  system software to take advantage of the PowerPC, much of the
  system still relies on the 68K emulator. Thus, even high-end Power
  Macintoshes are caught in a quagmire of 68K code, reducing their
  potential real-world performance even when running native
  applications.

  If 68K code is so slow, then how long will 68K emulators be
  around? That's simple: Apple has to keep a 68K emulator in the
  system forever.

  First, the Mac OS relies heavily on the 68K emulator, and though
  System 8 will contain substantially more Power Mac-native code
  than System 7.5.3, it's unlikely the entire operating system will
  ever be fully native. At a basic level, it's not worth the effort
  to port everything, particularly little-used, non-performance-
  related portions of the system.

  Second, Apple has a vested interest in making sure 68K code and
  applications continue to run. Almost every Power Mac user owns
  software written for 68K machines that will never be ported to
  PowerPC. A good example is Ambrosia Software's arcade classic
  Maelstrom, which is largely written in 68K assembly language.
  Porting Maelstrom to the PowerPC would be an enormous undertaking;
  yet, more than two years after the introduction of the Power
  Macintosh, Maelstrom continues to run fine in emulation, and is
  actually a good test of 68K emulators.

<http://www.ambrosiasw.com/Ambrosia_Products/Maelstrom.html>

  Keeping 68K emulation in the system doesn't mean that improvements
  can't be made. Apple's original 68K emulator was static,
  translating 68K instructions to PowerPC code one at a time.
  Emulation performance can be improved with larger Level 1 or Level
  2 processor caches (emulator performance is better on the PowerPC
  603e chip than the original 603 due to a larger Level 1 cache);
  however, it's also possible to build a smarter emulator.

  With the PCI Power Macs, Apple introduced a significantly faster
  dynamic recompilation (DR) emulator. The DR emulator watches the
  68K code for loops and stashes the translated PowerPC code for
  later use, rather than translating the same 68K instructions over
  and over again. However, the DR emulator comes with a slightly
  higher price in terms of compatibility: programs that do not
  operate correctly on 68040 machines with their processor caches
  enabled may not run correctly. Also, Apple's DR emulator only
  works on PCI Power Macs; the ROMs of earlier Power Macs don't
  support it.

  A good alternative is Speed Emulator, part of Connectix's Speed
  Doubler. (See TidBITS-292_.) Speed Emulator is also a DR emulator,
  and though it uses more memory than Apple's, it also significantly
  outperforms it and runs on any Power Mac. Speed Emulator's
  additional performance is particularly obvious in some areas; for
  instance, it significantly speeds up the Apple Event Manager, a
  feature particularly appreciated by AppleScript users.

<http://www.connectix.com/>

  Both Apple's and Connectix's emulators imitate a 68LC040, which is
  a problem if you need to use a 68K program with a program that
  specifically requires a floating point unit (FPU). In the 68K
  family, FPUs were originally a separate chip devoted to floating
  point math operations. With the 68040, Motorola built most FPU
  functions directly into the processor, then (in a cost-cutting
  move) removed them in the 68LC040. Programs requiring an FPU won't
  run under emulation on a Power Mac because they correctly
  determine that an FPU isn't available.

  If you need to use programs requiring an FPU on a Power Macintosh,
  you have two choices: SoftwareFPU and PowerFPU, both from John
  Neil and Associates. These programs emulate a 68K FPU, allowing
  68K programs that require an FPU to function. SoftwareFPU, a $10
  shareware product, works fine, though it's not PowerPC native and
  must pump its math calls through the 68K emulator. PowerFPU is a
  $20 commercial product that provides PowerPC-native FPU emulation.
  Since native PowerPC floating point functions are speedy,
  PowerFPU's performance can be quite good.

<http://www.jna.com/>


**The Magic Bus** -- When evaluating the performance of a
  computer, most users refer to the machine's processor type and
  clock speed, primarily because these terms are common,
  occasionally comparable, and liberally used in marketing
  materials. However, another major factor in a computer's overall
  performance is its bus, the main data path between the processor
  and other components.

  The easiest way to explain a bus is by analogy: think of your
  computer as a small, one-road town. Most of your computer's
  components live on the road, and the road must be used every time
  information has to travel between components. A traffic light
  controls travel, and a complex series of local laws governs who
  can go ahead, who has to wait, and how often people can get on or
  off the road. Two things control how _fast_ traffic moves: how
  many lanes the road has ,and how often the traffic light changes.
  One thing controls how _efficiently_ traffic moves: local traffic
  laws.

  In this analogy, the bus width is the number of lanes in the road,
  the bus speed is how often the traffic light changes, and the
  hardware architecture and operating system are the traffic laws.

* Bus Width: The bus width is literally how many bits can move
  across the bus at the same time. Power Macs have a 64-bit bus,
  meaning 64 bits can travel across the bus simultaneously. Previous
  Macs had a 32-bit bus, and early Macs had a 16-bit bus. As you
  might expect, a 64-bit bus is about twice as fast as a 32-bit bus,
  since it can move twice as much material in the same amount of
  time. However, a 64-bit bus is also more expensive to manufacture.

* Bus speed: The clock oscillator controls bus speed, as well as
  processor speed. Basically, a clock oscillator is a tiny quartz
  crystal that vibrates a certain number of times per second. It's
  like a metronome for a computer, controlling everything from disk
  access and screen redraws to memory access and networking, and
  making sure everything happens in sync.

* Hardware architecture: How traffic flows over the bus is a
  function of the computer's hardware and operating system design.
  For example, in older computers, writing data from RAM to a disk
  meant every piece of information in RAM had to go across the bus
  to the processor, then back across the bus to the disk system,
  which would write the information and report back when it
  finished. These days, it's more common for computers to have a
  "private road" between RAM and disks. There are numerous other
  instances of hardware and software engineering in all Macintosh
  models that strive to improve bus efficiency.


**Dishing Your Buses** -- The analogy above is a vast over-
  simplification - in reality, a Macintosh has a number of different
  buses, most of which exist in sub-systems. SCSI, Ethernet, serial
  ports, RAM, expansion slots (NuBus and PCI), and input devices all
  have separate buses, each of which has its own width and
  (sometimes) its own oscillator.

  Bus speed is an important factor when considering upgrades. Clock
  chipping, a popular, inexpensive method for upgrading Quadras and
  first-generation Power Macs, involves replacing the computer's
  clock oscillator with a faster one. Although it invalidates
  Apple's warranty and not all Macs can be clock chipped
  successfully (success rates are around 90 percent), replacing the
  clock chip speeds up the computer's processor and bus, often
  making for a good all-around performance improvement. For detailed
  information on clock-chipping, check out Marc Schrier's clock
  chipping FAQ.

<http://violet.berkeley.edu/~schrier/mhz.html>

  Many PCI Power Macs and clones have both their clock oscillators
  and processor chips on a removable CPU daughter card, providing a
  built-in upgrade path to faster clocks and processors. This design
  permits you to replace the processor and the clock oscillator at
  the same time. However, in many cases there's still a limit to how
  fast the main bus can go. In Apple's current models, the upper
  limit is 50 MHz; Power Computing's PowerTowers go to 60 MHz. This
  doesn't mean that daughter card upgrades won't be worthwhile for
  these machines, but rather that they won't improve the performance
  of every aspect of the system beyond a certain point.

  Similarly, upgrade cards for from vendors like Apple and DayStar
  for earlier Mac models (from the IIci through the Quadra series)
  should be evaluated not only on the basis of the promised clock
  speed of the PowerPC chip, but also in terms of the performance
  constraints imposed by other hardware. In many cases, these cards
  must traverse a comparatively slow, narrow bus to get data from
  disks, ports, other devices, and/or RAM, yielding real-world
  performance levels considerably lower than Power Macs with
  equivalent processor speeds. Though these upgrades might be
  adequate for being able to run PowerPC code, they're rarely
  equivalent to the performance of a used Power Mac and often cost
  just as much.


**The Myth Of Clock Speed** -- In the end, what does all this mean
  for buying a Macintosh these days?

  Be wary of hype surrounding the raw clock speed of a particular
  machine. Although processor speed is (of course) related to
  performance - and many computer vendors trumpet little more than
  the clock speeds of their machines - many other factors (processor
  type, cache, emulation, bus speed, system software, and more)
  contribute to a machine's real-world performance.

  As an example, Power Macs achieve their high processor speeds by
  using clock multipliers built into their PowerPC processors,
  allowing the chips to run faster than the machine's clock
  oscillator. There's no question this improves performance, but
  there are limits to how much bang-for-the-buck this technique will
  produce. There's a real performance difference between a 120 MHz
  machine using a 6x clock multiplier on 20 MHz bus and a 120 MHz
  machine using a 2x clock multiplier on a 60 MHz bus. Though both
  machines would function, the first machine will take much more
  time to access disks, networks, memory, and peripheral cards than
  the second machine. Even though they'd be roughly equivalent in
  terms of raw processor performance, the first machine is going to
  spend more of its processor cycles waiting for its hardware.

  Also, pay attention to what processor a particular machine uses.
  In terms of raw processor power, a 120 MHz PowerPC 604 is
  significantly (50 to 75 percent) faster than a 120 MHz PowerPC 601
  or 603e, just by the nature of the chip designs. However, in real
  world terms, a machine with a PowerPC 604 might only mildly
  outperform a 120 MHz 603e with a fast bus, fast video, fast disks,
  and a good emulator.

  If you can't judge computers by their clock speed, what can you
  use? Increasingly, the only meaningful measures of real-world
  performance are produced by benchmark applications like
  Speedometer, MacBench, and Norton Utilities System Info.

<ftp://mirror.aol.com/pub/info-mac/cfg/speedometer-402.hqx>
<http://www.zdnet.com/zdbop/macbench/macbench.html>

  I don't feel the results of these programs can be accepted as
  gospel. Though tests on my Macs produced results in the right
  ballpark for each machine, none of these applications produced
  consistent results in repeated testing. Still, programs like these
  at least attempt to analyze more than a processor's performance,
  and if results are sufficiently averaged across a wide range of
  configurations, they might give a reasonable idea of a machine's
  real-world performance.


**For More Information** -- These two articles have covered a lot
  of territory, and I hope they dispelled some confusion about what
  different bits of hardware do and how you can relate their
  specifications to real world performance. If you'd like more
  information, I'd recommend the following technical sources.

  For details on PowerPC processors, look at Motorola's and IBM's
  information, as well as the PowerPC FAQ:

<http://www.mot.com/SPS/PowerPC/library/library.html>
<http://www.chips.ibm.com/products/ppc/index.html>
<http://www.mot.com/SPS/PowerPC/library/ppc_faq/ppc_faq.html>

  If you're interested in how processors are officially benchmarked
  (and what a SPECint95 means!), check with the source:

<http://www.specbench.org/>

  Finally, if you're curious about how the PowerPC chip works in the
  middle of a Macintosh, I recommend this introduction from Apple's
  Developer University:

<http://dev.info.apple.com/du/intro_to_ppc/ppc0_index.html>


$$

 Non-profit, non-commercial publications may reprint articles if
 full credit is given. Others please contact us. We don't guarantee
 accuracy of articles. Caveat lector. Publication, product, and
 company names may be registered trademarks of their companies.

 This file is formatted as setext. For more information send email
 to <[e-mail]>. A file will be returned shortly.

 For information on TidBITS: how to subscribe, where to find back
 issues, and other useful stuff, send email to: <[e-mail]>
 Send comments and editorial submissions to: <[e-mail]>
 Issues available at: ftp://ftp.tidbits.com/pub/tidbits/issues/
 And: http://www.tidbits.com/tb-issues/
 To search back issues with WAIS, use this URL via a Web browser:
 http://wais.sensei.com.au/macarc/tidbits/searchtidbits.html
 -------------------------------------------------------------------